|To: Jay Appell 
|Date Sent: 89Nov21 at 5:51 am 
|From: uucp 


From uucp Tue Nov 21 05:51 EST 1989 
>From bu.edu! WSMR-SIMTEL20.ARMY.MIL! INFO-HAMS-REQUEST!WSMR-SIMTEL20.ARMY.MIL Tue 
Nov 21 05:47:04 1989 remote from cloud9 
Received: from cloud9 by es with UUCP; Tue, 21 Nov 89 05:51:54 EST 
Received: by cloud9.Stratus.COM (smail2.5) 
id AA15168; 21 Nov 89 05:47:04 EST (Tue) 
Received: from BU-IT.BU.EDU by BU.EDU (1.90) Tue, 21 Nov 89 01:36:39 -0500 
Received: from BUITA.BU.EDU by bu-it.BU.EDU (5.58/4.7) 
id AA29503; Tue, 21 Nov 89 01:36:36 EST 
Received: ‘from WSMR-SIMTEL20.ARMY.MIL by buita.bu.edu (11/17/89); Tue, 21 Nov 89 
01:35:49 EST 
Message-Id: <8911210635.AA17351@buita.bu.edu> 
Date: Mon, 20 Nov 89 23:15:08 MST 
From: cloud9!WSMR-SIMTEL20.ARMY.MIL!bu.edu! INFO-HAMS-REQUEST 


Reply-To: bu.edu! INFO-HAMS@WSMR-SIMTEL20.ARMY .MIL 
Subject: INFO-HAMS Digest V89 #911 
To: INFO-HAMS@WSMR-SIMTEL20. ARMY.MIL 


INFO-HAMS Digest Mon, 20 Nov 89 Volume 89 : Issue 911 


Today's Topics: 
(#1 in series) Listen to store security guards catch shoplifters 
INTERNET CALLSIGN SERVER CLIENT 
Military aircraft callsigns...Eugene Balinski (3 msgs) 
News From OSCAR-11 17-Nov-89 


Date: 21 Nov 89 01:04:33 GMT 
From: vsil!daver!lynx!neal@apple.com (Neal Woodall) 
Subject: (#1 in series) Listen to store security guards catch shoplifters 


Jim Grubs writes: 
Bob Parnass writes: 


>>It's getting near the holiday season -- a great time for listening 
>>to store security guards catch shoplifters. 


>Parnass, you've gone off the deep end with this irresponsible posting. Is 
>your hobby of electronic voyerurism so vital to you that it justifies aiding 
>criminals to evade detection and apprehension? I think you need to recheck 
>your priorities. 


Grubbs, I think that you are really in need of help. Lighten up, will you? 
How in the hell will listening to security guards catch petty thieves aid 
the theives in getting away? 


Bob, please don't let "Scrooge" Grubbs discourage you from posting. 


OR as Grubbs, happy holidays! 


Date: 20 Nov 89 22:56:59 GMT 
From: rochester!rit!ultb!cep4478@cu-arpa.cs.cornell.edu (C.E. Piggott) 
Subject: INTERNET CALLSIGN SERVER CLIENT 


In their infinite wisdom, the people at R.I.T. saw necessary to 
remove alternate port access via telnet. Thus, I lost access to the 
callsign server for a month or so. 


To counter this, I have written my own interface to the server. 


It is for any BSD compatible system (ultrix-32 is what I used, but it 
worked on the 4.3 machine here, too). (Sorry, I don't do VMS - 
actually, I wouldn't mind, if somebody would teach me how sockets 
work under vms). 


Anyhow, if you have telnet alternate port access already, you don't 
really gain much by using this program, except maybe a little typing 
here and there, so if you don't need it, it's probably best not to 
confuse yourself. The one thing you DO gain is that you can batch 

your requests into files, and use the < and > shell operators to 
process the lists. For example, you could create a file called "input" 
that looks like this: 


ka2rvo 

n2j] gw 

nigph 
and then type: 


ncall < input | lpr 


or something like that. 


Anyhow, here are the rules: 


(1) Please don't fool with the code. If you DO modify 
it, you may not distribute it further. 


(2) I'm not responsible for any of this. No warranties 
etc. Devon looked at the code and has no 
objection to the program, but it's not his 
problem, either :-) (actually, I'm a nice 
guy with lots of time to kill, so I'll help) 


(3) Please drop me a note if you find this thing useful. 
I'm a poor college student, and I'm very vain. =) 


So, here goes. 


Christopher E. Piggott 
internet: cep4478@ultb.isc.rit.edu 
packet: cep4478@wb2wxq 
uucp: ..!rutgers!rochester!ritcv!ultb!cep4478 
BITNET: cep4478@RITVAXA.BITNET 


* ncall.c - a local interface to Devon Bowen's internet callsign server 
* written by Christopher E. Piggott, N2JGW cep4478@ultb.isc.rit.edu 

* This program (c)1989 Christopher Piggott, all rights reserved. 

*/ 


d#Finclude <sys/types.h> 
dtinclude <sys/socket.h> 
dtinclude <netinet/in.h> 
dtinclude <netdb.h> 
#include <stdio.h> 
#Finclude <signal.h> 


dtdefine PORT 2000 
dtdefine PROMPT ">>" 


main () 
¢ 
int sock; 


(void) signal(SIGINT, SIG_IGN); 


if(isatty (0) ) 


(void) puts("Callsign client (local interface) written by Christopher 
Piggott, N2JGW\nCallsign server by Devon Bowen, bowen@cs.buffalo.edu"); 
sock = find_marvin(); 
process(sock); 


int find_marvin() 
/* open the connection to marvin, print hello message, and wait for prompt x/ 


q 
int sock; 
char buf[128]; 
struct sockaddr_in server; 
struct hostent xhp, xgethostbyname(); 


sock = socket(AF_INET, SOCK_STREAM, 0); 


if(!sock) 
oops("error creating socket"); 


server.sin_family = AF_INET; 


hp = gethostbyname("marvin.cs.buffalo.edu"); 
if(!hp) 
oops("error looking up host"); 


bcopy(hp->h_addr, (char *) &server.sin_addr, hp->h_length) ; 
server.sin_port = htons(PORT); 


if(connect(sock, (struct sockaddr_in «)&server, sizeof(server)) < 0) 
oops("connnect()"); 


(void) read(sock, buf, 6); 
(void) write(sock, "\377\375\001\377\375\003", 6); 


if(isatty(0)) 4 
if(!expect("Call", sock, 0)) /* this looks stupid, but "trust me" =) x/ 
oops("Didn't receive expected output"); 
(void) printf£("Call"); 
$ 


if(!expect(PROMPT,sock, (isatty(0) ? 1: 0) )) 
oops("Didn't receive expected prompt"); 
return(sock) ; 


$ 


oops(s) 


char xs; 
t 


perror(s); 
exit(1); 


process(sock_fd) 


int sock_fd; 

{ 
char c; 
int i; 


char bu£[128], call[64]; 


while(1) 4 
if(isatty(0)) 4 
(void) print£("\nCallsign? "); 
(void) fflush(stdout) ; 


if(! (fgets(call,63,stdin) && strlen(call)-1)) 
break; 


switch(«call) { 


case 'n': case 'N': /*x valid callsigns x/ 
case 'a': case 'A': 
case 'w': case 'W': 
case 'k': case 'K': 
(void) (void) sprintf£(buf, "call %s\r", call); 
break; 
case 'q': case 'Q': /* search by QTH x/ 
for(i=0;call[i]!='\O'&&call[i]!=' ';++1); 
(void) (void) sprintf£(buf, "city %s\r",&call[+ 
+1); 
break; 
case 'i': case 'I': /x view callserve info x/ 
(void) strcpy(buf, “info\r"); 
break; 
case 'l': case 'L': /* search by last name x/ 
for(i=0;call[i]!='\O'&&call[i]!=' ';++1); 
(void) (void) sprintf£(buf, "name %s\r",&call[+ 
+i]); 
break; 
case 'h': case 'H': case '?': /* help x/ 
list_help(); 
continue; 
default: /* oops! x/ 


(void) puts("\nBad command."); 
continue; 


if (write (sock_fd,buf,stxrlen(buf) ) <0) /x send command to marvin 
*/ 
oops("write() failed"); 
if(!expect("\n",sock_fd,0) ) /x absorb command echo x/ 
oops("Didn't get expected text"); 
putchar('\n'); 
if(!expect(PROMPT,sock_fd,1)) /* dump output to stdout x/ 
oops("Expected prompt from marvin"); 
$ 
(void) sprint£(buf, "quit\r"); /x issue terminating command x/ 
(void) write(sock_fd, buf, strlen(buf)); 
while(read(sock_fd, &c, 1)); /x flush fd x/ 
if(shutdown(sock_fd, 2)) 
oops("shutdown()"); 
* 


expect(s,fd, echo_flag) 
char xs; 
int fd, echo_flag; 


/* expect - wait for a contiguous group of characters 's' from stream fd x/ 
q 
char c; 
register int i=0, j, sl; 
sl=strlen(s); 
while(read(fd, &c, 1)) ¢{ 
if(c==s[i]) { 
if (++i==s1) 
break; 
$ 
else } 
if(echo_flag) { /x do not echo expected string x/ 
for (j=0;j!=1; j++) 
putchar(s[j]); 
putchar(c); 
$ 
i=0; 
$ 


return(i==sl); 


list_help() 

{ 

(void) puts("\n\ 

Callsign Server local interface commands: \n\n\ 

\ti - info about callsign server\n\n\ 

\tl lastname - search by surname\n\n\ 

\tgth city state - list all hams at QTH\n\n\ 

\t<callsign> - look up <callsign> - prefix must be W, K, A, or N\n\n"); 


Date: 21 Nov 89 00:11:20 GMT 
From: vsil!daver!lynx!neal@apple.com (Neal Woodall) 
Subject: Military aircraft callsigns...Eugene Balinski 


Jim Grubs writes: 
EUGENE BALINSKI writes: 
DUBE TODD writes: 


>>>My question is: Why would you be interested in what the call signs are 
>>>or represent? 


>>why am I interested ? Because it is one part of the hobby (the hobby 
>>being radio in general) that I enjoy. There are many people who enjoy 
>>scanning the mil aircraft band or the FBI or the CIA or the DEA etc. 


>...and the fact you're eavesdropping on things not intended for you is 
>irrelevant, right? 


I think that this response is somewhat flippant....if these things are 

so secret, then let the people or agencies doing the transmitting encrypt 
them! Hey, if the guy wants to listen to an un-encrypted transmission, I 
say more power to him! 


Look, the Russians pick up the military aircraft transmissions, so why 
shouldn't an American citizen be allowed to do the same? 


Neal 


Date: 21 Nov 89 00:24:32 GMT 
From: vsil!daver!lynx!neal@apple.com (Neal Woodall) 
Subject: Military aircraft callsigns...Eugene Balinski 


In article <10253@attctc.Dallas.TX.US> Steve Sampson writes: 


Dy ale ASA ora ORE OER As a political statement - I personally feel that 
>first they take your radios, then they take your guns. 


In the past I thought that it would be guns first, then radios. Now, however, 
I am beginning to believe that they will grab both at about the same time! 


The banning of guns or radios is a step that would be taken only by a police- 
state government that has grown too oppressive and distrustful of its own 
citizens....neither should be tolerated. 


>I would rather they forced secure communication on the Cellular Lobby, than 
>ban radios. 


I agree totally with this..... if the people who make and use cellular phones, 
or ANY communication equipment that used the electromagnetic spectrum for 
transmissions, think that their signals are of such a nature that they should 
be secure, then let them encrypt! 


If radio waves reach into my home, then I have a right to receive and attempt 
to demodulate them. The whole idea that people should be punished for receiving 
or demodulating radio signals was invented by those who have a monetary 
interest in some kind of communications, and who therefore do not care about 
people's personal freedoms. 


Date: 21 Nov 89 00:56:34 GMT 
From: vsil!daver!lynx!neal@apple.com (Neal Woodall) 
Subject: Military aircraft callsigns...Eugene Balinski 


Jim Grubs writes: 


>> Are you telling me that it is OK for the Russians to listen to SAC, but 


>> NOT OK for Americans to listen to SAC? 
>It's not OK for either. 


I would like to see you try to tell the Soviet intelligence people to stop 
listening to SAC because it is "not OK" for them to do so! 


When you say it is "not OK", do you mean in a legal or moral sense? If you 
mean in a legal sense, then please quote references....of course, I don't 
think that the Soviets will be deterred by any US laws! If you mean ina 
moral sense, then I would like to discuss your reasoning..... 


>The ECPA became necessary because electronic Peeping Toms abused the privacy 
>portions of the CommAct 


Wrong. The ECPA never was "necessary". 


It was seen as a slight disadvantage by the CTIA (Cellurlar Telephone Industry 
Assn.) that the cellular transmissions could be received by ordinary scanners, 
especially since the CTIA and cellular dealers had been advertising the 
cell-phones as "Snoop proof" (a total lie). The CTIA pushed the ECPA because 
they needed to be able to "assure" their customers that their communications 
were "secure". The ECPA was a total abuse of the law making system of the US. 


What a bunch of B.S.! If you want security, then encrypt! If your idea of 
"security" is to rely on a law that is practically unenforcable, then you 
are very confused. 


>You shouldn't have to trust me. I'm not involved. It's the message sender's 
>right to say "This is none of your business." 


It is also his right to encrypt! If he encrypts, then I have no problem with 
that. However, telling me that I cannot listen to something that is easy to 
receive and demodulate is absurd. 


>This right is protected by the constitution and laws of the United States. 


Really? In what way? There is no "privacy" clause in the US Constitution. 
The 4th Amendment might apply, but I don't think so. Think of this analogy: 
if I talk out-loud in a public place, do I have a reasonable expectation of 
privacy? If someone wanted to talk about "secure matters", they would most 
likely take some reasonable precautions. If someone wants to transmit some 
"secure info" over the public airwaves, I think it is up to him to encrypt 
that info. 


Date: 20 Nov 89 02:48:01 GMT 
From: att! tsdiag!ka2qhd! kd2bd@ucbvax.Berkeley.EDU (John Magliacane) 
Subject: News From OSCAR-11 17-Nov-89 


*xkUOSAT 2 COMPUTER STATUS INFORMATIONxx 


FAD1 OPERATING SYSTEM V2.0 

TODAY'S DATE IS 20 /11 /89 

UNIVERSAL TIME IS 2 :11 :14 DAY 2 
AUTO MODE IS SELECTED 

SPIN PERIOD IS - 315 

Z MAG FIRINGS = 0 

+ SPIN FIRINGS = 41 

- SPIN FIRINGS = 3 

RAM WASH POINTER AT 89C4 

WOD COMMENCED 20 /11 /89 AT 0 :0 :10 
WITH CHANNELS 1 ,2 ,3 ,61 , 

LAST CMD RECEIVED WAS 109 TO 0 WITH DATA 0 


ATTITUDE CONTROL INITIATED, MODE 1 
DATA COLLECTION IN PROGRESS 


DIGITALKER ACTIVE 


*xxx*k UoSAT-OSCAR-11 BULLETIN - 205 17th November 1989 xxxx 


UoSAT MISSION CONTROL CENTRE 
University of Surrey, Guildford, Surrey, GU2 5XH, England 


*xxkk UoSAT-D & E LAUNCH ADVANCED! xxx 


In a surprise move this week, the launch of the UoSAT-D & E spacecraft and the 
Microsats has been brought forward to 09 January 1990 - due to problems with 
the SUPERBIRD satellite that was scheduled for launch in mid-December. UoSAT- 
D & E are now undergoing pre-flight preparations before being shipped (with 
the launch integration team) to Paris on 30 Nov and then Kourou on @1 Dec in 
readiness for mating to the ASAP on 12 Dec. 


UoSAT-D & E have ccmpleted RF tests in the screen room at UoS and have been 
exposed to low temperature tests in the Clean Room 'freezer'at -20 C. Marc 


Fouquet, designer of the CCD camera on-board UoSAT-E, has been taking ‘bench- 
mark' images for comparison with orbital images. Totally ‘black' images have 
been collected to provide data for image processing using the Transputer Data 
Processing Experiment - also on UoSAT-E in collaboration with the European 
Space Agency. The additional solar simulation tests planned for next week 
have had to be cancelled due to the advance in departure date, and the 
spacecraft are now undergoing final cleaning and assembly in the Clean Room. 
Uplink & downlink calibrations in an RF anechoic chamber are planned for next 
week - providing that the chamber can be made available within the very tight 
schedule. Numerous visitors from several countries (as well as the UK) have 
recently come to UoS to view the new UoSAT spacecraft. 


xx Phase III-D xx 


AMSAT-DL announced that they have received substantial funding for the Phase 
III-D satellite which, as outlined by DJ4ZC's paper presented at the 1988 
AMSAT-UK Colloquium, will depart quite radically from its predecessors -- it 
is designed to have an RF output of 250 W, will weigh 200 to 400 kg and will 
be placed in a high-altitude Molniya orbit, similar to OSCAR-13. 


*k OSCAR-13 OPERATING SCHEDULE xx 


MODE B MA 060 to MA 160 NOTE: MODE S Operation will 
MODE JL MA 160 to MA 195 return Nov. 23rd after 
MODE B Beacon MA 195 to MA 200 the next AO-13 attitude 
MODE B MA 200 to MA 240 re-adjustment. 

OFF MA 240 to MA 060 


*x*x AMSAT OSCAR-10 Status Report xx 

Please DO NOT USE the Mode B transponder on AO-10 until 20-Nov-89 since A0-10 
does not have sufficient solar illumination to support the general use of the 
Mode-B transponder at this time. 

xxx Thanks for Reports *xx 

Thanks to all those who have sent in reports and telemetry from the last days 
of U0-9. Dave Guimont, Jr. WB6LLO still holds the record with telemetry at 
05:15 UTC (13 October). Can anyone do better? 

Reports received this week from: - 

Angus Newman, G6CSG 


xk $BID «xx 


Please use BID $U0SAT.205 for PR BBS use. 


AMPR : KD2BD @ NN2Z (Neptune, NJ) 

UUCP : ucbvax!rutgers!petsd!tsdiag! ka2qhd!kd2bd 
"For every problem, there is one solution which is simple, 
neat and wrong." -- H.L. Mencken 


End of INFO-HAMS Digest V89 Issue #911 
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